---title: "Transcrição da Prova Teórica 1 — nome: "
disciplina: "Gestão de Projetos de Software"
codigo_disciplina: "GPS"
avaliacao: "Prova Teórica 1"
periodo: "2026-2"
data: "2026-10-19"
discente:
  nome: "Fillipe Tomaz Carvalho França"
  matricula: "20233004600"
curso: "Engenharia de Computação"
turma: "Unidade Timóteo"
nota_total: 9.5
nota_maxima: 25.0
legibilidade_percentual: 88
metadados_transcricao:
  transcritor: "Antigravity Assistant (Visão Computacional)"
  data_transcricao: "2026-10-19"
  grau_fidelidade: "Fiel (ipsis litteris), preservando rasuras e omissões"
format:
  html:
    toc: true
    theme: cosmo
  pdf:
    documentclass: scrartcl
    papersize: a4
    geometry:
      - margin=20mm
---


# Transcrição da Prova Teórica 1 — Fillipe Tomaz Carvalho França

## Questão 1

### 1.1 (1,5) Projeto vs. operação — três características com evidências:
Nesta questão, o professor agente é uma operação. As suas três principais características é o uso de um projeto produzido (modelo de IA), dependência de recurso externo (tokens) e a dependência de servidores web.

### 1.2 (2,0) Duas alternativas de trade-off sem sacrificar qualidade + impacto no Triângulo de Ferro:
Aumento da equipe de desenvolvedores (+ Custo) e a diminuição de funções do projeto (- Escopo, + tempo)

### 1.3 (1,5) Ciclo de vida e justificativa (preditiva, ágil ou híbrida):
A operação é uma abordagem ágil de curta duração, na qual não se precisa com atualizações bruscas após o fim do desenvolvimento.

---

## Questão 2

### 2.1 (1,5) EAP de dois níveis (substantivos, regra dos 100%, $\ge 3$ pacotes de trabalho):
[NÃO RESPONDEU / EM BRANCO]

### 2.2 (2,0) Duas issues completas no GitLab:
[NÃO RESPONDEU / EM BRANCO]

### 2.3 (1,5) Milestones vs. Sprints + quando Kanban é mais adequado:
[NÃO RESPONDEU / EM BRANCO]

---

## Questão 3

### 3.1 (1,5) DoD vs. DoR — critérios objetivos e garantia de qualidade:
O DoD é o conceito que descreve uma aplicação em regra, ela esteja pronta para o uso geral. A funcionalidade não estara pronta caso ela esteja insegura para o uso, com enorme risco de vazamento de dados, além de não cumprir com a regra local de proteção de dados, rolando até problemas jurídicos.

### 3.2 (1,5) Classificação dos quatro custos da qualidade (PAF):
a: Avaliação  b: Prevenção  c: Falha externa  d: Falha Interna

A falha externa é a de maior custo devido ao fato de ser descoberta pelo usuário final, causando pânico na equipe que deve corrigi-lo o mais rápido possível, assim, aumentando o seu custo.

### 3.3 (2,0) Regra 1-10-100 (custo de correção) aplicada a LLMs:
[NÃO RESPONDEU / EM BRANCO]

---

## Questão 4

### 4.1 (1,5) Risco vs. problema (Cap. 6) + quadrante na matriz P$\times$I e estratégia de resposta:
```
[Espaço para desenho/diagrama da Matriz PxI]
Marcado "X" no quadrante inferior direito (Médio Impacto / Baixa Probabilidade)
```
O evento é considerado um problema, visto que foi uma falha humana. A probabilidade de um profissional cometê-la é baixa, mas o impacto causado é sim considerável pelo prejuízo causado a equipe.

### 4.2 (1,5) Três ações imediatas + uma ação preventiva (defesa em profundidade):
Suspender o uso do software, convocação urgente dos desenvolvedores / organização de um plano de contingência. A ação preventiva é a troca de chave de API, disso vez, no repositório privado ou em pastas como a (.env).

### 4.3 (2,0) Risco de entrada modelado (causa, P, I, mitigação, contingência) + mitigação de saída + artefato de documentação:
Uma ADR poderá ser usada como um registro de documentação, visto que o README é usado para introduzir o software ao usuário final.

---

## Questão 5

### 5.1 (1,5) Comunicação síncrona vs. assíncrona no GitLab + prática/ritual de registro de decisões:
As reuniões em voz é a forma mais confortável e direta no debate de ideias e no alinhamento de equipe. Já o assíncrono é o aviso claro do que foi alterado no software. Envio de emails diretamente para a equipe deixando claro as ações que foram e que serão feitas.

### 5.2 (1,5) Matriz Poder $\times$ Interesse dos 5 stakeholders, premissas e estratégia de comunicação:
```
[Espaço para desenho/diagrama da Matriz Poder x Interesse]
- Manter satisfeito: 1 (Alunos)
- Gerenciar de perto: 3 (Equipe de desenvolvimento)
- Monitorar: 4 (Provedor da API)
- Manter informado: 2 (Professor), 5 (Coordenação)
```
Os professores devem se manter informados sobre o nível de satisfação dos alunos, e as atualizações / correções que a ferramenta sofreu. Então, poderíamos usar o email da instituição + um canal de mensagens instantâneas para que eles se mantenham cientes de qualquer notícia.

### 5.3 (2,0) Conflito pedagógico vs. técnico — Thomas-Kilmann (1 escolha justificada + 2 inadequadas):
A abordagem recomendada pelo time técnico é considerada pelos principais pedagogos do mundo como a abordagem mais saudável, devido a capacidade de motivação para o raciocínio do aluno.